This certainly looks like an improvement, but it's still possible for any user to DoS the machine until a reboot with for x in $(cat /etc/passwd | cut -f1 -d:); do touch /tmp/pytest-of-$x; done;.

This certainly looks like an improvement, but it's still possible for any user to DoS the machine until a reboot with for x in $(cat /etc/passwd | cut -f1 -d:); do touch /tmp/pytest-of-$x; done;.

Great callout Michael! This attack route is now blocked by a safety check before creating the directory: If a non-directory file is blocking the path (e.g. placed by another user), we attempt to remove that file and then retry.

Great callout Michael! This attack route is now blocked by a safety check before creating the directory: If a non-directory file is blocking the path (e.g. placed by another user), we attempt to remove that file and then retry.

This cannot work unfortunately: the file is owned by the attacker, so I cannot delete his files from /tmp unless I am root. I indirectly mentioned this in #13669 (comment) where I pointed out that it's silly to tell me to fix the situation.

I don't want to sound like an asshole always coming back with new caveats to every approach, but the truth is that this is very old class of vulnerability and all of the ways to exploit it are well-known. (I was not auditing the code, I just saw the fixed path one day and knew immediately that it would be exploitable.) The solution is to use a carefully-created randomly-named path; so if someone proposes a solution that does not involve mkstemp() or something like it under the hood, then it's very easy to look up what the problem was with that approach.

Great callout Michael! This attack route is now blocked by a safety check before creating the directory: If a non-directory file is blocking the path (e.g. placed by another user), we attempt to remove that file and then retry.

This cannot work unfortunately: the file is owned by the attacker, so I cannot delete his files from /tmp unless I am root. I indirectly mentioned this in #13669 (comment) where I pointed out that it's silly to tell me to fix the situation.

I don't want to sound like an asshole always coming back with new caveats to every approach, but the truth is that this is very old class of vulnerability and all of the ways to exploit it are well-known. (I was not auditing the code, I just saw the fixed path one day and knew immediately that it would be exploitable.) The solution is to use a carefully-created randomly-named path; so if someone proposes a solution that does not involve mkstemp() or something like it under the hood, then it's very easy to look up what the problem was with that approach.

Fixed!

Previously, TempPathFactory created a fixed, predictable directory (/tmp/pytest-of-<user>) as the rootdir, which enabled a class of attacks: an adversary could pre-create files or symlinks at that path to DoS pytest or exploit TOCTOU races (CVE-2025-71176).

I've replaced _try_ensure_directory() with tempfile.mkdtemp(), which atomically creates a randomly-suffixed directory (pytest-of-<user>-XXXX) that cannot be predicted or pre-empted by an attacker. os.chmod(0o700) is applied unconditionally after mkdtemp, and the existing fd-based fchmod inside _safe_open_dir provides defense-in-depth against TOCTOU.

Because mkdtemp now produces a fresh directory every session, add _cleanup_old_rootdirs() to prune stale rootdirs from previous sessions, retaining only the keep most recent (by mtime).

Fixed!

The new approach looks good to me FWIW.

mkdtemp() guarantees that the directory will be 0700 and owned by the current user, so the pre-existing chmod/stat safeguards conveniently become redundant if this approach is adopted :)

the pre-existing chmod/stat safeguards conveniently become redundant if this approach is adopted :)

TY Michael, and let's leave it to another enthusiastic coder ;) and close the book on this CVE